This disclosure relates generally to the field of database management and administration. More particularly, this disclosure relates to migrating an Information Management System (IMS) Full-Function database to an IMS High Availability Large Database (HALDB).
IMS refers to both a hierarchical database and an information management system. The IMS database component stores data using a hierarchical model in blocks of data known as segments. There are three basic forms or types of IMS databases: Full-Function; Fast-Path; and HALDB. Full-Function databases can have primary and secondary indexes, are accessed using DL/I calls, and store data using Virtual Sequential Access Method, VSAM (a native z/OS access method) or Overflow Sequential Access Method, OSAM (an IMS-specific access method). HALDBs are an extension of IMS Full Function databases and were designed to provide better availability, better handling of extremely large data volumes, and online reorganization to support near continuous availability.
One significant difference between a Full Function database and a HALDB is how paired logical child relationships are represented. In a Full Function database, each segment having a bidirectional physically paired logical relationship with another segment has a pointer to its physically paired child segment's physical parent (i.e., a pointer to its logical parent). In contrast, physically paired logical relationships in a HALDB are represented directly. That is, a HALDB segment has a direct pointer to its physically paired logical child segment.
Due to the indirect nature of the paired logical child relationship representation adopted by Full Function databases, the conversion of large Full Function databases to HALDBs can involve an extremely large number of input-output (I/O) operations (to locate each segment's paired logical segment). Because I/O operations are time intensive, conversion of large Full Function databases to HALDBs has been impractical at best and, from a business stand-point, often times impossible. This problem is exacerbated by the fact that IMS does not support logical relationships between a HALDB and a non-HALDB (e.g., a Full Function database). As a consequence, all databases that are logically related to one another must be migrated together (to the HALDB format).
To better understand the scope of this process, FIG. 1 (Full Function database unload operation 12) and FIG. 2 (Full Function to HALDB load operation 200) illustrate a prior art conversion process. Referring first to FIG. 1, a first Full Function database is selected for conversion (block 13). A first segment from this database is then unloaded (block 14) and checked to see if it has a physically paired logical child segment (block 15). It will be recognized the existence of physically paired logical relationships is retained in an IMS database's Database Descriptor (DBD). Thus, acts in accordance with block 15 may utilize the selected database's DBD to determine if the segment obtained during block 14 (the “current” segment) has a physically paired logical child segment. If the current segment has a physically paired logical child segment (the “YES” prong of block 15), that database in which the paired child segment exists is, if needed, opened (block 16). Each child segment of the current segment's logical parent is then retrieved and searched until the exact paired child segment is identified (block 17). Once the paired logical child segment is identified, its address is saved in the selected database's unload file (block 18).
Following the acts of block 18 or if the current segment does not have a physically paired logical child segment (the “NO” prong of block 15), a check is made to determine if the selected database has any remaining segments to unload (block 19). If at least one segment remains to be unloaded (the “YES” prong of block 19), that segment is retrieved (block 14), whereafter unload process 12 continues at block 15. If all segments have been unloaded (the “NO” prong of block 19), unload operations 14-19 are repeated for each logically related Full Function database (block 20). The result of unload process 12 is two or more unload files 21.
Referring to FIG. 2, prior art Full Function to HALDB load operation 200 begins by selecting an unload file from the set of unload files 21 generated in accordance with unload process 12 (block 205). The HALDB into which the Full Function database content (i.e., the content of the selected unload file) is to be placed is defined (block 210), whereafter the selected unload file's content is loaded into the newly defined HALDB (block 215). If all of the unload files generated in accordance with unload operation 12 (i.e., unload files 21) have been loaded into new HALDBs (the “YES” prong of block 220), load operation 200 is complete. If at least one unload file remains to be processed (the “NO” prong of block 220, the acts of blocks 205-220 are repeated. The completion of unload operation 12 and load operation 200 constitutes a Full Function to HALDB conversion process.
The extent of required I/O operations needed to effect prior art unload operation 12 and, in particular, actions associated with block 17 may be understood with respect to FIG. 3. As shown, illustrative prior art Full Function database 1 has segment 2 that has a physically paired logical relationship with segment 3 in Full Function database 4. As shown, segment 2 includes pointer 5 to segment 3's physical parent 6 (to the logical parent of segment 2). Similarly, segment 3 in database 4 includes pointer 7 to its logical parent 7 (i.e., the physical parent of segment 2).
Thus, after segment 2 is unloaded from database 1 in accordance with block 14 and found to have a physically paired logical child segment in accordance with block 15, every child segment of parent segment 6 (represented as a “stack” of segments in FIG. 3) must be retrieved from database 4 one at a time and their data content compared to the data content of segment 2. Only when a match is found does operation 12 know the location (i.e., address) of segment 2's physically paired logical child segment 3. This information is needed to represent a physically paired logical relationship in database 1's HALDB incarnation (defined in accordance with block 210).
In general, each segment retrieval from database 4 represents an I/O operation. In commercial IMS databases, the number of child segments under any given parent segment (e.g., segment 6 or 7) can number in the millions. As a result, locating segment 2's physically paired logical child segment 3 may entail millions of I/O operations. In addition, when database 4 is itself unloaded (in accordance with 12), all of parent 7's segments must be retrieved one at a time and their data content compared to the data content of segment 3. For large Full Function databases having many logically paired relationships with other (large) Full Function databases, the time required to perform conversion unload process 12 may run from 1 day to several tens of days. For many commercial operations where these databases are used to store critical business information, taking a database offline for sufficient time to perform this conversion is not an option.